Together, these mean a crate on MSRV 1.89 can use #![forbid(unsafe_code)] while still doing SIMD dispatch — no unsafe, no nightly, no feature gates.

This isn't true. You still need unsafe, it just gets hidden/abstracted. I was in the process of writing up a long response, but realized there's no point in arguing with what's probably an LLM hallucination.

I think there is an argument that we can trust is_*_feature_detected(x), and that you can make a provably sound abstraction on top of that which is simple enough to audit. That said, it does generate a trampoline, which does contain an unsafe block to call the inner function - the function itself is not unsafe annotated, though, so the only unsafety is the target_feature hop/switch. Rust itself computes the set math at compile time to determine if a call is safe or if you will be required to get a new capability token.

Archmage takes the generate-everything approach to ensure token types never get mismatched, and most of the complexity has been around how to group features into pragmatic supersets, name things, make such code testable, and ergonomics. Using a cpu instruction a cpu doesn't support is unsound, true, but in reality is quite like exit() rather than something exploitable, AFAIK. I haven’t had any such instructions slip through the cracks yet.

The dependency safe_unaligned_simd crate is more load-bearing, but trivial to audit in a different way - it's just checking slices-to-pointer logic. I don't own that crate, but I trust it.

Given archmage+forbid unsafe, I feel comfortable letting LLVMs prototype with intrinsics all day and explore every idea I can come up with.

Magetypes, on the other hand, takes an approach similar to fearless_simd (something I wish I had looked at earlier), and uses generics and associated types to make simd use 95% as fast as raw intrinsics. It is much harder to audit, so I parse the rust source code to build a db of which intrinsics rust considers safe per feature token, then use that for generating and validating the simd types. It's labeled experimental, but it's actually working better than I hoped. I haven’t run into any soundness holes with either crate yet.

The design problem of generating unsafe in a proc-macro is not the lack of unsafe on the surface, any encapsulation does that, it's the instability of encapsulation. Instead of auditing some piece of code as-is you need to certify the full range of possible outputs. That is after all the definition of soundness, correct under all inputs. The proc-macro as-implemented breaks the usual approach of having a module boundary with finite snippets that are self-contained encapsulations of the unsafe parts. You named the upside of this, the ability to have by-construction semantics, but the crate would need to be (more) rigorously structured for that. In the end I'll still trust a by-construction approach that leverages types and traits (the types themselves may be generated) more; I think. Not the least because this has a more reasonable avenue to be compatible with automated proof approaches (kani etc) where necessary.

There are more convincing ways to write a proc-macro; the derives of bytemuck and zerocopy do not just unsafe impl but generate a sufficient bound necessary for the impl to work. The actual proof is then (supposedly) done at compile time. I say supposedly since there are problems with those crates where having specific imports at the usage site can make them mistake types in the bound structure, they miss fields added by later proc-macros, etc. So really they are not sound. (Still useful but not sound).